[レポート] 5 Key Benefits for Building a Modern Data Pipeline

奈良県でリモートワーク中の玉井です。

Snowflake社の下記のウェビナーを受講したので、レポートします。

ウェビナー情報

公式情報

概要

Modern data pipelines make it faster and easier to extract information from the data you collect. Snowflake’s modern, cloud-built architecture streamlines data engineering, delivering the performance and simplicity required to extract value from data.

Join this Master class session on Building Modern Data Pipelines in Snowflake, to learn which characteristics to look for when considering a data pipeline. Hear from InterWorks, the value this can provide to the business user by enabling speed to insights and data-driven decisions

登壇者

補足

「今の時代のデータパイプラインでおさえるポイントはここ！」という感じの内容でした。そして、そのポイントは、SnowflakeのSnowpipe、Stream、Taskといった機能を使うことで簡単にできるということも話に含まれていました。

レポート

モダンデータパイプラインとは

Snowflakeの機能を使うと、モダンデータパイプラインを効果的に作成することができます。まず、Snowflakeの全体的なアーキテクチャについて触れたいと思います。Snowflakeは単なるウェアハウスではなく、単なるデータレイクでもなく、単なるストレージでもなく、構造化されたリレーショナルデータベースでもあるし、半構造化データゾーンでもあります。ここ5～10年の間、これが効果的にデータエンジニアリングの要件を牽引してきたもので、それ以前は、通常、データエンジニアリングの要件を満たすことができませんでした。ETLやELTはデータウェアハウス内で行われていたか、カスタムコーディングや外部ツールでETLを行っていたかなど、非常に明確な分岐点がありました。しかし現在では、データエンジニアリングの下にデータを持ち込むことで、データパイプライン開発を実際のプラットフォームに戻し、データやコンピュートが存在する場所に戻すという流れになっています。プラットフォームのパワーの多くを得ることができますし、すべてのものをネイティブで統合することができます。

なぜモダンデータパイプラインがいるのか

まずは、モダンデータパイプラインがどのようなものであるべきか、ということを議論してみましょう。まず、シンプルさを取るために、「Central」なアプローチを取ります。特にデータサイズが巨大な場合、最大の問題の一つは、パイプラインへのETL層がデータと共同で配置されていない場合です。その後、データが前後に移動するための大規模なネットワーク転送コストは、アジリティを阻害する可能性があり、また、それはスケーラビリティの問題を引き起こす可能性があります。我々はデータを集中化して、コンピューティングとストレージが存在する場所に戻ってパイプラインを持ってくることを望んでいます。すべてのものを可能な限り近くに置いて、ネットワークなどへの依存を減らします。

第二に、「Easy」でなければなりません。これは非常にシンプルなポイントですが、セットアップやメンテナンスが簡単でなければなりません。また、監視も容易でなければなりません。今日は、これら3つを満たしながら、超複雑なパイプラインを構築する時代です。そして、それが可能なツールがあります。そのための要件やニーズは常にありますが、私たちが目にする大半の人は、シンプルなツールセットを使って素早く効率的に物事を進めようとしています。それは表現力があり、「Powerful」でなければなりません。

特定の機能だけに限定することはできませんし、ユーザーはおそらく（データ変換における）障害物にぶつかります。その場合、ユーザーは別のパイプラインツールに飛び込んで別のロジックを実行しなければなりませんが、Snowflakeでは利用可能なすべての機能を活用することができます。公開されている豊富な機能を利用して、これらの多くのデータ変換を行うことができます。また、UDFやストアドプロシージャなどを使って拡張することも可能です。

これらはすべて、モダンデータパイプラインで結びつけることができます。なぜこれを正しく構築する必要があるのか、あなたは知っているはずです。なぜなら、単に技術的に良くするためだけではなく、何を提供しようとしているのか、5つの重要なメリットをこれから理解するからです。

モダンデータパイプラインを構築するための5つの鍵

まずは「Simplicity」です。可動部の量を最小限にします。Snowflakeは、Snowpipe、Stream、Taskという機能を持っています。これらはSnowflakeのモダンデータパイプラインの3本の柱です。私たちがやりたいことは、10、20、30にもなるオブジェクトや機能性を必要としない部分の量を減らすことです。確かに、非常にリッチなものを作成できる可能性はありますが、非常に複雑なソリューションにさらされることになり、アジリティを阻害する可能性があります。

2つ目は、私たちが推進している主なメリットである「Agility」です。開発環境で迅速に開発を行い、それを本番環境にデプロイするというシンプルな意味での「Agility」です。これもまた、シンプルで、可動部分が少なければ少ないほど、本番環境への導入がシンプルになります。また、DevOpsの実践を可能にすることです。組織内のDevOps志向のスタッフが、データエンジニアリングパイプラインなどに優れたDevOpsプラクティスを実装して、CI/CDといった、最高のものを提供できるようにすることができます。

3つ目は、「Accessibility」についてです。モダンデータパイプラインを使用していても、それが非常に限られたユーザーに限定されていることがあります。複雑な言語であれ、複雑なフレームワークであれ、認定された人材を持っているパートナーを見つけるのに苦労します。「Accessibility」としては、これは既存のSQLを活用することです。SQL開発者の大規模なコミュニティが存在することは誰もが知っていることですが、パイプラインの構築に参加するために全員のスキルを活用することができます。

4つ目は、ダウンタイムなしのスケーラビリティを持つことです。これも非常に重要です。特にクラウドな今の時代にこれは必須です。ダウンタイムを許容したくないし、限定的なスケーラビリティも許容したくありません。ワークフローの要求に応じて、自動的にスケーリングしたいのです。ダウンタイムを考慮に入れずに、Snowflakeを使って自動化します。特にSnowflakeを使ってテストしたり、以前のドキュメントやプレゼンテーションを見たことがある方は、Snowflakeがどのようにそれを可能にするのか、その経験やメッセージングから理解できると思います。

最後に、これは私が非常に重視していることですが、継続処理やイベントドリブンなフレームワークに移行することで、ジョブのオーケストレーションの複雑さを軽減することができます。しかし、スケジュール上で物事をキックオフし、スケジュールを管理し、スケジュールによってキックオフされるオブジェクトの依存関係などを管理しなければならないという考えは、スケジュールに依存し始めています。ワークフローはイベントによってトリガーされるべきです。これは私たちのSnowflakeのSnowpipe機能では重要です。パイプラインは継続的にデータを処理しているので、「午後2時や3時よりも午後1時に実行するようにスケジュールを組もう」という必要はありません。一度すべてのロジックをインスタンス化して、データが到着してから継続的に処理を行うと、その時点で自動化のメリットが得られます。そうすれば、それがビジネスにどのような影響を与えるのか、ビジネスにどのように展開するのかに焦点を当てることができるようになります。

これがSnowflakeの世界でどのように見えるかを図にしてみました。

一番上のセクションにあるOLTPデータベースやエンタープライズアプリケーションあたりを見てみましょう。このようなコアデータのデータ取込機能は、COPYコマンドなどを使って一括してロードすることができます。これは非常に一般的なものですが、私たちがモダンデータパイプラインで見ようとしているのは、これらのワークロードだけではなく、それらを組み合わせることです。例えば、Snowpipeの自動取込は、データをS3のようなクラウドストレージに配置します。それらのファイルが配置されると、自動取込はイベントドリブン型のフレームワークを介して、バックグラウンドでメッセージキューを効果的に使用し、そのデータをステージングテーブルにロードしています。そして、これらのステージングテーブルから、Snowflakeプラットフォーム全体のデータをターゲットテーブルへと移動させます。

ステージングテーブルからは、図のようなStreamを作成できます。これは、ステージングテーブルのすべての変更を登録します。Streamの大きな利点の1つは、処理をしなくて済むことです。例えば、テーブルが大きくなっても、処理済みの行の再処理などでテーブルを常にループする必要はありません。データが入ってきたときに処理するだけなので、計算効率が良く、コスト効率も良いので、既に処理したデータを重複して処理する必要がありません。これが効果的なリードストリームオブジェクトです。

また、Taskは、そのStreamに対して効果的に実行するための反復的なデータ処理ロジックを「タスク」として作成します。そして、出力結果を生成します。この図の場合、ターゲットテーブル1、ターゲットテーブル2となります。このような流れを繰り返しているので、出力テーブルからStreamを作成し、それらのデータを処理するTaskを実行しています。このソリューションには多くの可動部分はありません。主にSnowpipeを中心に展開され、従来のバルクローディング機能でデータを取得します。とてもシンプルでいいですね。

Snowflakeの機能をさらに深堀り

では、Snowflakeの各コンポーネントをさらに詳しく見ていきましょう。

Snowpipe

Snowpipeは、先ほどデータを自動的に取り込むという話をしましたが、これは効果的なイベントドリブン型のサーバーレスプロセスです。ファイルが到着するとイベントが発生し、それがキューに送られ、Snowflakeにロードされます。一度セットアップしてしまえば、あとは手を煩わせることはありません。あとは、データが正しくロードされているかどうかなどを確認するために、それを監視することができます。しかし、データが利用可能になれば、あなたはデータの操作に集中することができます。これの主な利点は、データが利用可能になるまでの待ち時間を短縮できることです。レポートや分析、テーブルを最新の状態に保つことができます。Snowpipeはこの待ち時間を短縮するのに役立ちます。先ほど話したように、Snowpipeは継続的なパイプラインの基礎となるものです。モダンデータパイプラインの5つ目の鍵である継続性を考えれば、Snowpipeは、このフレームワークのイベントドリブン型のコアであるため、その点で非常に重要な要素です。繰り返しになりますが、すべて自動ロードをベースにしており、イベントドリブンなので、データロードに関わる多くの依存関係を減らすことができます。バックエンドで発生しなければならないオーケストレーションの手動作業の多くを取り除きます。

Steram

Streamオブジェクトを使用することで、ソーステーブルに発生したINSERT・UPDATE・DELETEを表示します。そして、それらの変更行だけを操作することができます。明らかに多くの場合、データのサイズが小さく、過去のデータセットも明らかに小さくなっているので、処理時間が短縮されます。これにより、Snowflake内の仮想ウェアハウスを長く稼働させる必要がなくなり、コスト効率が大幅に向上します。これにより、より真のクラウド経済モデルが実現し、本当に効率的な計算コストだけを支払うことができるようになります。Streamの設定は簡単で、変更は自動的に公開されます。また、特定のテーブルに複数のStreamを設定して、異なるコンシューマーに対応させることもできます。

例えば、私があるソーステーブルに興味を持っているとします。また、請求チームはテーブルに異なる関心を持っていて、別々のStreamを持って、別々のワークフローを作成して、独自のデータスライスを作成することができます。お互いのStreamなどを中断することがないので、ほぼマルチテナントに近いですね。Snowpipeと組み合わせることで、テーブルだけでなく、行単位で処理することもできます。Snowpipeはアペンドのみのフレームワークなので、先ほど説明したデータだけを処理することになります。

Task

これは、DML文やストアドプロシージャを実行するタスクで、スケジュールに応じて実行することができます。例えば、1分ごと、2分ごとにデータが到着したときなどです。また、依存関係に基づいたワークフローを作成するために連鎖させることもでき、Task1を実行して、それが完了したらTask2を実行する、というようなこともできます。必要に迫られている場合は、次のようにします。ディメンションモデルやData Vaultなどをロードするときに、Taskを使用して、そのTaskのフローをオーケストレーションすることができます。Streamと一緒に使用することができますが、単体で任意のSQLをいつでも実行するために使用することもできます。例えば、JSON等の半構造化データは、リレーショナルデータベース（構造化データ）の形に整える必要があります。それを簡単にしたい場合は、基本的にすべてのデータを正規化し、典型的なリレーショナル形式でそれを公開するためにTaskを使用して非常に簡単に実行できます。

分単位の同期や、IoTデータの分析なども可能です。StreamからのIoTデータを分析して、IoTイベントをSnowflake内の他のデータソースと相関させることで、センサーや機械などで発生していることを最大限に活用することができます。また、通常の不動産の識別を自動化するだけでも、特定のソースからのデータが特定のパターンにマッチしているか、標準化されたデータを使用しているか、釘があるべきでない場所に釘がないかなどを確認するために、一定の間隔で実行されるデータ品質チェックのようなTaskの束を実行しているかもしれません。

Cloning and Timetravel

最後に、CloningとTimetravelがどのように機能するかに触れておきたいと思います。データパイプラインを初期開発し、ロジックをテストし、本番環境に対応できるかどうかを確認する際に、これらの機能を有効にすることができます。本番環境のデータベースのクローンを数秒でスピンオフして、開発環境で作業を開始し、本番環境のベータテストですべてを検証することは非常に簡単です。そしてパイプラインを本番環境にデプロイし、本番環境でも同様に作業を開始します。パイプラインが本番環境に入っていれば、いつでもすぐに別の環境に移行してロジックを変更してテストしてから元に戻すことができます。また、クローニングを使って定期的にスナップショットを作成することもできますので、パイプラインを検査して、ある瞬間に何が起こっているかを確認したい場合には、そこで何が起こっているかを見ることができます。同様に、何らかの理由でデータの破損が発生した場合も同様です。パイプライン内では、特定の時点から簡単にロールバックして再生することができ、事業継続を再開することができます。

まとめ

最後に、私たちが何を学んだのか、もう一度まとめておきたいと思います。SnowpipeのSteramとTaskの話をしましたが、この3つの機能はは、CloningとTimetravelによって可能になりました。これら4つの要素を組み合わせて、シンプルさとアジリティ、アクセシビリティを実現しています。繰り返しになりますが、Snowflakeのアーキテクチャとクロスクラウドデプロイメントを活用しています。事実上ダウンタイムなしの即時のスケーラビリティ、継続的な処理、そしてデータパイプラインの構築方法の新時代をもたらします。

業界例（Interworks社より）

資源

資源業界では、大量のデータをデータウェアハウスにロードしたいと言うことは珍しくありません。外部の会社から情報をもらってきたのかもしれません。もしくは、現場から情報を受け取ったのかもしれません。私は、このようなデータセットを一度にロードする場合、最も抵抗の少ない方法を探します。彼らのビジネス分析を促進するために、その情報をできるだけ早くデータウェアハウスに入れてあげたいのです。しかし、私は、それが面倒な作業であることは望んでいません。数年前のDBA用語で考えればわかると思います。テラバイト級の情報をデータウェアハウスに入れるとなると、DBAは既存のサーバーに空き容量があるかどうかを考えることになるでしょう。また、それを処理するための計算能力や、顧客に別のサーバを立ち上げてもらう必要があるかどうか、といったことも考える必要があります。さらに、セットアップの管理時間も考慮しなければなりません。率直に言って、これまで経験した見積の中には、天文学的なものもありました。

今では、クライアントと仕事をしていて、このような質問をされたとき、この業界でも、どんな業界でも、一回だけのデータロードが必要なときは、笑顔で「はい」と答えることができます。

「1時間ください」。文字通り、1時間で15TBのCSVをSnowflakeに取り込むことができます。ORCやParquetのデータを教えてくれれば、1時間で約5TBのデータをロードすることができます。私はCUIを起動します。これはSnowshellという小さなツールです。彼らのデータの上で暗号化を押してデータをSnowflakeのステージングレイヤーに送ります。私は文字通り、いくつかのコマンドを発行します。

コストの面では、そのデータを取り込むためのコンピュートには100ドルくらいかかるでしょうし、1TBのデータを保存するには1年で300ドルかかるかもしれません。先ほどのDBAの例と比較すると、数万ドルの費用をかけてデータを取り込むことができますが、これは非常に簡単なことです。

エネルギー

エネルギー業界での話です。風力発電所の風力タービンにはセンサーが付いていて、データ量は天文学的です。毎日、何億ものデータやタグが発生します そのようなシナリオにどう対処すればいいのでしょうか。

Snowflakeは、ほぼリアルタイムで情報を取り込むことができる機能を持っています。この例では、風力発電所がデータを生成していました。Taskとしては、データがS3のデータレイクに入ると、データレイクをスキャンして、定期的にそのデータを取り込んでいます。そのためにSnowpipeを使うこともできましたが、1時間に2～3回、Taskを起動する方がはるかに簡単でした。しかし、クライアントが必要なもう一つのデータセットは、膨大なデータで、本社から、タグの読み取り値が何なのか、IoT値が何なのかを正確に説明する詳細データが必要です。ビジネスがそのデータを使う必要があるときはいつでもS3バケットに飛び込んでくるでしょう。このようにして、SMSのようなメッセージング技術を使って、Snowpipeをトリガーにして、Snowflakeからネイティブ取込機能を利用して、データが入ってくると、そのバケットに移動してデータを取得し、それをステージングエリアレイヤーに持ち込むことができます。これが完了すると、セカンダリTaskを実行することができます。最新のIoTデータを探して、最新のメタデータが利用可能になったら探します。そしてそれを変換して、フラット化されたデータセットにします。IoTのようなものは、データウェアハウスやスタースキーマに変換する価値はありません。IoT情報のネイティブ構造は、おそらくネイティブで十分なのですが、行と列を持つようにフラット化したい場合もあるでしょう。実際には約200行のコードをまとめて、S3の下でのアクセス権の設定、Snowpipeを介したデータの取り込みを明らかにしたことになり、かなり良い結果となりました。そして、データを2つのフラット化されたデータセットにまとめるための統合作業を行いました。

医療

この業界の顧客には20以上の重要なシステムがあります。それらは全てオンプレミスで、SQL ServerやOracle、他の様々なアプリケーション、バックエンドが混在しています。ですから、ある作業をしたい場合、一日の終わりにみんなが帰った時にやって欲しいと思います。1分単位でできる場合もあります。 なぜなら、そのシステムはすでにその負荷に対応しているからです。このような場合には、Snowflakeを、別のELTソリューションで拡張するのですが、Snowflakeを採用する理由の多くを考慮して、私たちが選んだのはMatillionでした。Matillionは稼働しているときにのみ料金が支払われます。これは、この特定の業界にとって大きな利点でした。

私たちは、これら20のシステムから安全な方法でデータをSnowflakeに直接送信できるようにする必要がありました。また、既存のKimballモデルのプレゼンテーションレイヤーをサポートしているため、データやデータ分析ソリューションを使って、可能な限り迅速にSnowflakeと同等のものに移行できるようにしたいと考えていました。これは、企業レベルのELTソリューションのように、多様な取込パターンからデータをSnowflakeに取り込むことで、Snowflakeを強化する方法です。そして、StreamのようなSnowflakeの機能の一部を活用して、CDC側の作業を支援しています。従来のデータウェアハウスの構築をデータエンジニアリングで考えると、通常はデータのステージングが半分を占めますが、今回の大部分は、データを統合し、変化を識別し、それをプレゼンテーションレイヤー（Stream）に提示する部分でした。

コンサルタント

最後にコンサルタント業界…弊社の例を紹介します。これ以上の例はありません。私たちはSnowflakeの顧客です。私たちはSnowflakeの初期の採用者の一人であり、Snowflakeへの情熱があったからこそ、Snowflakeのパートナーになることができたのです。しかし、世界中に200人のデータエンジニアリング、データアーキテクチャ、データアナリティクスのスタッフがいて、全員が1つのSnowflakeインスタンスを利用しています。タイムトラベル機能のようなものや、スワップテーブルコマンドを使って1行のコードでテーブルを直接スワップできるような単純なものでも、開発環境と本番環境の間で情報を変換する際のオーバーヘッドを最小限に抑えながら、スプリントや反復的な作業ができるようになりました。これまでは開発環境から本番環境への移行にはかなりの時間がかかっていましたが、今では数分で完了することができるようになりました。そういった観点から見ると、現代のDevOpsは間違いなくSnowflakeのおかげであることがわかりますね。

おわりに

データ移行もあると思いますが、最近だとやはりIoTが流行ってきており、データが矢継ぎ早に飛んでくる環境も増えてきていると思います。そして、そのデータを素早く分析できる状態が求められていると思います。Snowflakeはそういったニーズに応えるために、いち早く便利な機能をどんどん実装していってますね。